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ABSTRACT 


\ 

\ 

Organizational  structure  has  long  been  recognized  as 
having  an  important  iapact  on  an  organization's  ability  to 
accomplish  its  objectives.  This  paper  provides  managers  of 
software  development  projects  with  an  analysis  of  the  impor¬ 
tance  of  several  elements  of  organizational  structure,  and 
of  hew  they  can  use  this  knowledge  to  make  decisions  which 
will  have  a'  positive  impact  on  the  success  cl  their 
projects.  The  structural  elements  discussed  are  specializa¬ 
tion  of  activities,  size  of  the  work  group,  and 
standardization  of  activities. 
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is  software  development  projects  have  becoae  sore  and 
sore  complex,  organizations  have  developed  various  struc¬ 
tures  to  accomplish  them  in  an  effective,  efficient,  and 
timely  manner.  This  aspect  of  the  organizational  adaptation 
process  involves  manipulating  elements  of  organizational 
structure  in  such  a  way  as  to  optimize  the  utilization  of 
the  organization's  scarce  resources.  Stor.er  [Hef.  1]  iden¬ 
tifies  four  major  determinants  of  organizational  structure: 
the  organization's  strategy  for  achieving  its  goals;  the 
skills  and  needs  of  the  people  employed;  the  technology 
employed;  and  the  size  of  the  organization  and  its  subunits. 
Management,  by  making  decisions  concerning  these  determi¬ 
nants,  seeks  to  develop  the  structure  which  will  be  most 
successful  in  accomplishing  the  goals  of  the  organization. 
These  managerial  decisions  are  of  extreme  importance  because 
"the  choices  which  top  management  cake  are  the  critical 
determinants  of  organizational  structure  and  process." 
[Hef.  2:  p.548]  Because  of  the  impac*:  of  these  decision s,  i*- 
is  very  important  that  managers  of  a  software  development 
project  understand  what  the  elements  of  organizational 
structure  are  and  how  they  can  be  manipulated  to  improve  the 
performance  of  the  development  process. 

Three  elements  of  organizational  structure  noted  by 
Stoner  [Ref.  1]  will  be  the  focus  of  this  paper.  The  first 
element  will  be  the  specialization  of  activities.  This 
concerns  the  breaking  down  of  the  overall  project  into 
component  activities  and  assigning  personnel  with  special¬ 
ized  training  to  accomplish  those  activities  for  which  their 
training  makes  them  most  suited,  and  in  which  they  will  be 
most  productive.  The  objective  of  the  chapter  on 
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specialization  of  activities  sill  be  the  asking  the  critical 
decisions  of  the  optiaal  combination  of  specialized  labor  +o 
employ,  and  the  optiaal  quantity  of  individual  specialized 
labor  to  apply  to  the  softs  are  development  process. 

The  second  eleaent  sill  be  the  size  of  the  work  group. 
An  analysis  of  the  iapact  of  work  group  size  on  productivity 
will  be  aade.  The  factors  which  influence  work  group 
productivity  will  be  explored,  and  approaches  to  aitigating 
the  negative  factors  while  enhancing  the  positive  factors 
will  be  examined.  The  size  and  composition  of  a  work  group 
with  high  productivity  potential  will  be  investigated,  and 
the  managerial  and  systems  design  techniques  needed  to 
support  this  work  group  will  also  be  noted. 

The  third  and  final  eleaent  will  be  the  standardization 
of  activities.  The  benefits  of  activity  standardization 
within  a  software  development  project  will  first  be 
discussed  in  general  tens.  The  standardization  of  one 
phase  cf  the  process  will  then  be  analyzed  in  detail  to 
identify  specific  contributions  and  relevance  to  the  overall 
management  process. 
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A.  RBAS01S  POB  SPECIALIZATIOH 

One  of  the  most  important  elements  of  organizational 
structure  is  the  specialization  of  activities.  This 
specialization  in  the  organizational  sense  includes  the 
breaking  down  of  the  project  into  smaller,  specialized 
tasks.  The  benefits  of  division  of  work  have  been  repeat¬ 
edly  demonstrated  throughout  the  history  of  civiliza+ion. 
The  order  of  magnitude  improvements  in  productivity 
resulting  from  division  of  work  have  had  profound  impact  on 
the  world's  industrial  development.  Division  of  work  is 
important  because 

no  one  person  is  phvsically  able  to  perform  all  of  the 
opera-ions  in  host  complex  tasks,  nor  can  arv  one  person 
acquire  all  the  skills  needed  to  perform  the  various 
tasks  that  make  up  a  complex  operation.  Thus,  ir.  order 
to  carry  out  tasks  rsauiring  a  number  of  steps,  it  is 
necessary  tc  rarcei  out  the  various  Darts  of  the  task 
amcna  a  number  of  people.  Such  SDScialized  division  of 
work' allows  gecpie  to  learn  skills  and  become  expert  at 
their  individual.  lob  functions.  SimDlified  tasks  can  be 
learned  in  a  relatively  short  period  cf  time  and  be 
completed  quickly.  [Ref.  1:  p.  25h ] 

In  a  complex  task  such  as  a  software  development  project 
it  would  be  impractical  to  assign  one  person  to  accomplish 
the  task  by  himself.  In  order  to  achieve  a  high  guality 
product,  this  person  would  not  only  have  to  be  expert  in  all 
areas  of  software  development,  he  would  also  have  to  be  able 
to  provide  his  own  clerical  services,  administative 
services,  computer  services,  etc.  This  one-man  approach  is 
impractical  for  a  multitude  of  reasons,  not  the  least  of 
which  is  the  development  time  that  would  be  required.  »ith 
development  times  for  projects  running  into  the  hundreds  or 
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thousands  of  man-years,  only  the  smallest  of  projects  would 
be  possible.  Therefore,  division  of  work  in  a  complex 
development  project  is  absolutely  essential  to  the  success 
of  the  project. 

B.  S PECIALIZ  ATI  CN  IN  SOFTWARE  PROJECTS 

The  software  development  project  is  often  broken  down 
into  a  sequence  of  tasks,  phases,  or  activities  such  as 
requirements  analysis,  system  design,  system  coding,  system 
test,  etc.  This  division  cf  the  overall  task  into  many 
subtasks  has  been  widely  discussed  in  the  literature. 

As  the  task  itself  is  divided  into  a  variety  of 
subtasks,  so  to  must  the  overall  work  requirement  be  divided 
among  many  individuals.  As  discussed  above,  this  division 
of  labor  is  necessary  to  produce  a  quality  product  within 
time  and  cost  constraints.  The  division  of  labor  allows 
individuals  to  specialize  and  become  expert  at  certain 
skills.  Systems  analysts,  programmers,  technical  analysts, 
and  datatase  administrators  are  some  of  the  specializations 
within  software  development  projects.  The  chief  programmer 
team  concept  as  described  by  Brooks  [Ref.  3:  p.  32-35], 

makes  clear  distinctions  between  the  skills,  duties,  and 
responsibilities  of  its  beam  members.  The  specialization 
within  the  chief  programmer  team  includes  a  chief 
programmer,  assistant  programmer,  administrator,  editor, 
secretaries,  clerk,  toolsmith,  tester,  and  language  lawyer. 
This  type  of  team,  the  individuals  within  it  and  their 
duties  will  be  discussed  later  in  the  paper. 

C.  HANAGEHE1T  DECISIONS 

The  thrust  of  this  chapter  will  be  towards  developing 
generic  conceptual  frameworks  for  the  management  decisions 
concerning  the  combination  and  quantity  of  the  specialized 
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labor  skills  to  employ.  The  following  management  decision 
questions  will  be  addressed: 

1)  Shat  is  the  optimal  mix  of  the  different  types  of  labor 
to  employ  in  the  software  development  process? 

2)  Shat  is  the  optimal  quantity  of  a  particular  type  of 
labor  to  employ? 

1.  The  iabo ;  Mix  Decision 

a.  The  Production  Process 

The  software  development  process  is  a  production 
process  which  transforms  a  particular  set  of  inputs  (e.g. 
systems  analyst  labor,  programmer  labor,  computer  services, 
etc.)  into  a  desired  output.  Figure  2.1  models  this 
process. 


Figure  2.1  Software  Development  Hodel. 
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The  relationship  between  the  inputs  into  the 
process  and  the  maximum  output  based  upon  those  inputs 
represents  the  production  function  for  the  process.  In 
other  words,  given  the  technology  applied,  the  output  of  the 
process  is  a  function  of  the  inputs  employed  in  the  process. 
Brooks  [Bef.  31  and  Tried  [  Bef.  4]  have  demonstrated  that  if 
the  other  inputs  are  held  constant  while  one  type  of  labor 
is  allowed  to  increase,  that  input  will,  at  some  point,  show 
decreasing  marginal  productivity  and  will  eventually  display 
a  negative  marginal  productivity.  Figure  2.2  illustrates 
these  findings  with  respect  to  programmer  labor.  The  slope 
of  the  curve  in  Figure  2.2  represents  the  marginal  product 
of  programmer  labor  with  respect  to  total  lines  of  code 
produced. 


Figure  2.2  Programmer  Labor  Productivity. 
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Figure  2. 3  A  Software  Development  Isoquant. 

Points  A  and  3  on  the  isoquant  represent  two 
different  coabirat ions  of  programmer  and  systems  analyst 
labor  capable  of  producing  the  same  amount  of  software;  as 
such,  they  represent  two  different  technological  processes 
(within  the  given  technology)  used  in  the  production  of  the 
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software.  The  slope  of  the  curve,  therefore,  represents  the 
marginal  rate  of  technological  substitution  (MBTS)  of 
programmer  labor  for  systems  analyst  labor.  It  can  also  be 
shown  that  the  marginal  rate  of  technical  substitution  is 
equal  to  the  ratio  of  the  aarginal  products  of  the  inputs 
(Bmf.  5:  p.  158].  In  symbols: 

MR  IS  =  -MPp/MPsa  (eqn  2.1) 

where: 

MPp  »  marginal  product  of  programmer  labor 
MPsa  *  aarginal  product  of  systems  analyst  labor 
MRTS  *  marginal  rate  of  technical  substitution. 

t.  The  Costs 

Tf  we  assume  that  the  organization  has  a  limited 
amount  cf  funds  to  expend  on  the  inputs  tc  the  prciuc-ior. 
process,  and  that  the  total  cost  of  the  fixed  inputs  remains 
constant  and  is  less  than  the  total  amount  available,  then 
there  exists  an  amount  which  is  available  to  partition  among 
the  variable  inputs:  programmer  and  systems  analyst  labor. 

In  symbols: 

M  *  Pp*Qp  ♦  ?sa*Qsa  (eqn  2.2) 

where: 

M  *  the  total  amount  available  for  programmer  and 
systems  analyst  labor 

Pp  *  the  price  of  a  unit  of  programmer  labor 

Psa  «  the  price  of  a  unit  of  systems  analyst  labor 

Qp  *  the  quantity  of  programmer  labor  used 

Qsa  *  the  quantity  of  systems  analyst  labor  used. 
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If  we  graph  aquation  2.2  we  can  represent  the 
various  possible  combinations  of  programmer  and  systems 
analyst  labor  that  can  ba  aguired  for  the  aeount  8  by  a 
straight  line  as  in  Figure  2.4  .  This  line  is  called  the 
isocost  curve  for  these  input  combinations.  The  slope  of 
the  isocost  curve  is  negative  and  can  be  shown  to  be  equal 
to  ?p/Psa. 


Figure  2.4  Isocost  Curve. 

If  a  family  of  the  previously  developed  isoquant 
curves  is  superimposed  upon  the  isocost  curve  of  Figure  2.®, 
as  in  Figure  2.5,  it  is  possible  to  graphically  determine 
the  optimum  mix  of  program aer  and  systems  analyst  labor  to 
employ  in  the  software  developaent  process. 


}6 


amount  of  programmer  labor 


Figure  2.5  The  Optimum  Labor  Hix. 


Q 1,  Q2 ,  and  Q3  represent  isoquants  in  increasing 
order  cf  quantity  of  software  produced.  There  may  be  any 
number  of  isoquants  represented  on  the  graph,  but  it  can  be 
seen  that  output  will  be  maximized  for  a  given  cost  (N)  at 
the  point  where  the  isocost  curve  is  tangent  to  the  highest 
isoquant  curve.  In  Figure  2.5  this  is  point  B,  and  Q2  is 
the  maximum  quantity  of  software  that  can  be  produced  for 
the  qiven  dollar  amount  available  for  programmer  and  systems 
analyst  labor.  Alternately,  it  could  be  stated  that  H  is 
the  minimum  amount  that  would  have  to  be  spent  on  programmer 
and  systems  analyst  labor,  other  factors  held  constant,  in 
order  to  produce  a  desired  quantity  Q2.  points  A  and  C 
represent  subopt iaua  utilization  of  resources  because  the 
same  dollar  apount  is  being  expended  to  produce  a  smaller 
amount  of  output  (Qi)  than  it  is  possible  of  producing. 


Additionally,  figure  2.5  shows  that,  if  other  factors  of 
production  are  held  constant,  it  is  not  possible  to  produce 
sore  than  Q2  (for  exaaple  Q3)  with  a  limit  of  a  dollars 
available  for  programmer  and  systems  analyst  labor. 
Therefore,  fros  figure  2.5  it  is  demonstrated  that  the 
optimum  mix  of  systems  analyst  aid  programmer  labor  is 
represented  by  the  quantities  isa  and  Qp  respectively. 

There  is  still  more  information  available  from 
figure  2.5  .  As  shown  above,  the  slope  of  the  isocost  curve 
is  equal  to  the  ratic  or  the  prices  of  the  inputs  (-??/?$»), 
and  the  slope  of  the  isoquant  curve  is  equal  to  the  marginal 
rate  of  technological  substitution  or  the  ratio  of  the 
marginal  products  of  the  inputs  (-MPp/MPsa) .  The  optimum 
mix  has  been  shewn  to  be  the  point  of  tangency  between  the 
isocost  curve  and  the  isoquant  curve.  Therefore,  at  the 
optimum,  the  ratio  of  the  prices  of  the  inputs  will  be  equal 
to  the  ratio  of  their  marginal  products.  The  optimal  combi¬ 
nation  cf  programmer  and  systems  analyst  labor,  therefore, 
is  where: 


Pp/Psa  *  MPp/tlPsa  (eqn  2.3) 


or  alternately  where: 


HPsa/Psa  =  MPp/Pp 


(eqn  2.4) 


This  second  equation  reveals  that  the  optimum 
mix  exists  where  the  marginal  productivity  of  a  dollar's 
worth  of  systems  analyst  labor  is  equal  to  a  dollar's  worth 
of  programmer  labor. 
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This  conclusion  makes  intuitive  sense  and  car.  be 
generalized  for  any  nueber  of  inputs  [Ref.  St  p.  175].  what 
tha  relationship  says  is  that  if,  at  any  point,  output  can 
be  increased  by  taking  a  dollar  from  input  x  and  applying 
that  dollar  to  input  Y,  than  it  is  beneficial  to  do  so.  The 
equilibria*  point  will  necessarily  be  where  the  ratio  of  the 
marginal  productivity  to  cost  for  all  inputs  is  equal. 

2.  I&SL  L&k&£ 

The  second  problem  is  to  decide  the  optimal  quantity 
of  an  input  to  utilize  in  the  software  development  process. 
Programmer  labor  will  be  used  as  a  representative  input. 

It  was  shown  above  that  tha  marginal  productivity  of 
programmer  labor  in  the  production  of  software,  holding 
other  factors  constant,  is  positive  over  the  relevant  range. 
In  other  words,  ar.  incremental  increase  in  proorammer  labor 
will  result,  up  tc  a  point,  in  an  incremental  increase  in 
the  amount  of  software  produced.  The  amount  of  the  increase 
in  programmer  labor  required  to  produce  the  incremental 
increase  in  software  produced  is  called  the  marginal  input 
requirement  of  programmer  labor  in  h he  production  of  soft¬ 
ware  (MIP.p)  .  If  the  market  price  of  programmer  labor  is  ?p, 
then,  in  order  to  achieve  a  marginal  increase  in  software 
production,  a  marginal  cost  (HCJ  equal  to  the  price  of 
programmer  labor  multiplied  by  the  marginal  input  require¬ 
ment  of  programmer  labor  in  the  production  of  software  will 
be  incurred.  The  equation  is: 

MC  =  P  p*MI Rp  (eqr.  2.5) 

or  alternately,  since  it  can  be  shown  that  the  marginal 
input  requirement  is  equal  to  the  inverse  of  the  marginal 
product: 
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MC  *  Pp*1/MPp 


(eqn  2.6) 


The  marginal  revenue  (MB)  received  by  selling  the 
incremental  amount  of  software  produced  can  also  be  calcu¬ 
lated.  If  the  market  price  of  th9  software  produced  is  Rs, 
then  the  margin al  revenue  is  equal  to  this  market  price 
multiplied  by  the  increase  in  software  produced  as  a  result 
of  an  incremental  increase  in  prcarammer  labor.  This  second 
term  is  the  marginal  product  of  programmer  labor  in  the 
production  of  software.  The  marginal  revenue  equation  is: 


MS  3  Rs*MPd  (eqn  2.7) 

Because  the  flow  of  funds  for  costs  ana  revenues 
occur  at  different  periods  in  time,  it  is  necessary  to 
discount  them  to  present  values  before  comparing  then: 

-ft  „  a 

Present  Value  of  MC  *  Pp*SlIFp*e  (eqr.  2.8) 

-rt  „  . 

Present  Value  of  MR  *  Rs*MPp*e  (eqn  2.9) 

The  difference  between  the  present  value  of  the 
marqinal  revenue  and  the  present  value  of  the  marginal  cost 
is  the  net  present  value  of  a  marginal  increase  in  the 
amount  of  programmer  labor  used.  If  this  net  present  value 
is  positive,  that  is  if  the  present  value  of  marginal 
revenue  is  greater  than  the  present  value  of  marginal  cost, 
then  it  is  profitable  to  increase  the  amount  of  programmer 
labor  used.  If  the  net  present  value  is  negative,  then  it 
is  profitable  tc  decrease  the  amount  of  programmer  labor 
used. 
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all  other 


At  the  optieua,  all  other  factors  reaaining 
constant,  prograaaer  labor  (or  any  other  input)  should  be 
acquired  to  the  point  where  the  present  value  of  earginal 
revenue  equals  the  present  value  of  earginal  cost.  In 
syebcls  this  is  where: 


-ft  -ft 

Pp*MIRp*e  *  Rs*KPp*e 


(eqn  2.10) 


A  probles  in  lapis  renting  this  type  of  cor.cep-uai 
framework  is  the  difficulty  of  developing  an  accurate 
production  function  for  rhe  software  development  process, 
especially  in  vise  of  rhe  paucity  of  good  databases  or.  tha 
subject.  A  majcr  benefit  of  this  type  of  conceptual  frame¬ 
work  is  irs  compatibility  with  linear  programming  methods  as 
shown  by  Ein-Dor  and  Jones  [Ref.  6], 
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A.  IVTBOOOCTZOI 

The  complex  nature  of  software  development  projects  has 
necessitated  the  decomposition  of  the  overall  task  into  a 
multitude  of  lesser  tasks  and  the  assignment  of  groups  of 
people  to  accomplish  those  tasks.  Dne  would  think  that  the 
larger  the  group  of  people  assigned  to  a  task,  the  shorter 
would  be  the  completion  time  for  the  task.  Therefore,  in 
order  to  meet  project  deadlines,  attempts  have  been  made  to 
speed  the  completion  of  complex  software  development 
projects  by  simply  adding  more  manpower  to  the  project.  The 
fallacy  of  this  belief  has  been  widely  noted,  most  promi¬ 
nently  ir.  Brooks  *  widely  read  book  She  mythical  Month  in 
which  Brooks  identified  some  of  the  factors  which  restrained 
increased  group  size  from  resulting  in  decreased  project 
completion  time;  and  in  which  he  described  how  "adding 
manpower  tc  a  late  software  project  makes  it  later.” 
[Ref.  3:  p.  25]  The  impact  of  this  phenomenon  on  the  soft¬ 
ware  production  function  was  discussed  in  the  previous 
chapter.  This  chapter  will  analyze  how  and  why  the  size  of 
the  work  group  contributes  to  this  phenomenon,  and  how  the 
negative  influence  or.  productivity  may  be  mitigated. 

B.  PRODUCTIVITY  IB  GROUPS 

From  studies  as  well  a3  from  our  own  work  experience  we 
know  that  members  of  a  group  working  on  a  task  do  not  spend 
all  of  their  time  doing  constructive  work.  Some  percentage 
of  the  time  is  spent  on  coffee  breaks,  meetings,  illness, 
training,  vacations,  communicating,  socializing,  etc.  For  a 
10  member  group  "the  non-productive  time  expected  for  each 
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member  is  25  percent  for  vacation  and  the  like;  10  percent 
for  idle  tiae;  and  a  base  of  10  percent  for  time  spen* 
communicating:  a  total  of  45  percent.  We  aay  therefore 

estiaate  that  55  percent  of  each  employees  tiae  can  be 
considered  productive  in  a  group  of  up  to  10  eaployees." 
[Hef.  4:  p.  3]  Fried  defines  productivity  in  a  software 
development  project  as  "developing  a  systea  with  the 
following  characteristics:  -  Maintainability  (documented, 

modular,  etc.)  -  Effectiveness  (meets  actual  user  needs) 
Efficiency  (uses  minimal  resources)."  [Ref.  4;  p.  8] 

The  portion  cf  non-productive  tiae  c  ha*  is  most  variable 
with  group  size  is  the  communication  time.  If  each  member 
of  the  group  has  to  interact  with  each  other  in  the  accom¬ 
plishment  of  the  task,  the  number  of  interactions  rises 
dramatically  with  the  number  of  people  involved.  If  K  were 
the  number  of  people  in  the  group,  the  number  of  interac¬ 
tions  (N)  would  be  given  by  the  formula: 

3  *  K*  (K-l)  /2  (ecn  3.1) 


This  formula  shows  that  the  number  of  interactions  in 
the  group  increases  in  exponential  fashion  with  an  increase 
in  group  size.  This  communications  effort  has  proven  to  be 
a  determining  factor  of  productivity  time  in  a  group.  Fried 
[Ref.  4]  has  developed  the  following  formulae  for  computing 
the  the  percentage  of  productivity  time: 

Pt  *  K*(T*  .55  -  .3001*  (K*  K- 1  /2)  )  (eqn  3.2) 

where ; 

Pt  *  productivity  time 

T  «  individual  employee  hours  per  work  period 
K  *  the  number  of  people  in  the  group. 
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The  productivity  percentage  in  the  work  group  is  therefore: 
Pp  »  100  *(.  55  -  .0001*  K*(K-1)/2  )  (eqn  3.3) 

where : 

Pp  *  percentage  of  productive  time 
K  =  the  number  of  people  in  tne  group. 


Solving  the  above  equations  for  a  10  member  group 
working  a  40  hour  work  week: 


Pt  *  10  *  (40 *  .55  -  .0001  (10*  10-1  /2)  )  ~  218.2 
Pp  *  10  0  *  (.  55  -  .00  01  1  0*  (10-  1)  /2  )  =  54.55 


whereas  for  an  8  0  member  group  working  ‘■he  same  hours: 


Pt  *  80*  (40*  .55  -  .  000  1  *  (30*  80-1  / 2 )  )  ■  748.8 
Pp  ■  100  *(.  55  -  .00  01*  80*  ( 80-  1 )  /2  )  =  23.4 


Table  I  demonstrates  how  the  productivity  percentage 
varies  for  groups  of  various  size. 

Fried  C  Bef.  4],  and  Weinberg  [Bef.  7]  have  experienced 
this  inverse  relationship  between  group  size  and  produc¬ 
tivity  in  complex  projects  with  which  they  have  been 
associated.  Furthermore,  Fried  postulates  that  it  is 
possible  to  reach  a  point  of  negative  marginal  productivity. 
This  is  consistent  with  Brooks'  [Bef.  3]  earlier  findings 
that,  after  a  point,  adding  manpower  can  increase  time  to 
completion  rather  than  decrease  it. 
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Group  Size 

TABLE  I 

and  Productivity  Percentage 

212.02.  Siz§ 

Proiuctivitv  Fercentacre 

10 

54.55 

20 

53.  1 

40 

47.2 

60 

37.3 

30 

23.4 

i - 

- -  - - -  -  ■  - - - - i 

c.  SHALL  PROJECT  TEAMS 

The  above  findings  suggest  that,  on  the  basis  of  produc¬ 
tivity  time,  project  teams  should  be  created  which  are  of 
limited  size.  A  team  with  two  members  would  seem  -.0  have 
the  highest  productivity  percentage;  but  the  additional 
coordination  and  communication  that  would  be  required 
between  groups,  as  well  as  the  limited  division  of  labor 
possible  within  the  group,  would  eliminate  any  possible 
advantages.  Alternately,  too  large  a  group  results  in  low 
or  negative  marginal  productivity. 

Brooks  [Bef.  33  encountered  this  dilemma  of  balancing 
the  desireable  aspects  of  small  groups  against  the  absolute 
need  to  produce  the  large  and  complex:  OS/360  system  within 
time  and  budget  constraints.  He  described  his  problem  as 
follows; 

Por  effiency  and  conceptual  integrity,  one  prefers  a  few 
good  minds  doing  design  and  construction.  Yet  for  large 
systems  one  wants  a  way  to  being  considerable  manpower  to 
bear,  so  that  the  product  can  make  a  timely  appearance.  How 
can  these  two  needs  be  reconciled?”  [Ref.  3;  p.  31] 


The  answer  that  Brooks  [Ref.  3],  Hills  [Ref.  8],  and 
others  have  advocated  is  the  chief  programmer  teaa  concept. 
This  concept  calls  for  a  10  person  teaa  headed  by  a  chief 
prograaner  who  designs,  codes,  tests,  and  documents  the 
systea;  and  who  is  totally  responsible  for  the  product.  All 
the  other  teaa  aeabers  are  tasked  with  supporting  the  chief 
prograaner  in  his  duties.  The  other  aeabers  of  the  teaa  and 
their  duties  are: 

-  The  “copilot"  who  serves  as  the  primary  assistant  and 
understudy  to  the  chief  programmer; 

-  The  adainistra tor  who  handles  the  logistics  and 
administrative  coordination  for  the  team; 

-  The  editor  who  reviews  the  chief  programmer’s  rough 
documentation  and  performs  the  necessary  editing  and 
reworking  required  to  produce  the  final  product; 

-  Two  secretaries,  one  each  for  tna  administrator  and  th- 
aditor,  for  the  necessary  typing,  filing, 
correspondence,  etc.; 

-  The  program  clerk  who  maintains  the  program  product 
library; 

-  The  "toolsmith"  who  provides  basic  utilities,  creates 
aacro  libraries,  and  in  general  facilitates  and  ensures 
the  adequacy  of  computer  services; 

-  The  tester  who  designs  and  plans  module  and  systems 
testing,  produces  test  cases,  test  data,  etc.; 

-  The  language  lawyer  who  is  expert  in  the  chosen 
programming  language  and  can  advise  the  chief 
programmer  on  sophisticated  or  intricate  uses  of  the 
language.  (Ref.  3:  pp.  3  2*35] 
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The  hierarchy  of  individuals  performing  specialized 
functions  in  support  of  a  group  leader  not  only  provides  the 
benefits  of  division  of  labor  and  specialization  discussed 
earlier,  it  also  provides  conceptual  integrity  in  design  and 
coding,  as  well  as  simplifying  the  interpersonal  communica¬ 
tion  required.  This  reduct  ion  in  coimunication  requirements 
coupled  with  the  small  size  of  the  team  results  in  a  higher 
productivity  percentage  for  the  team.  Figure  3.1  illus¬ 
trates  the  communication  patterns  within  the  chief 
progranaer  team.  [Hef.  3:  p.  36] 
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Figure  3.1  Communication  Patterns  in  10-dan  Programming  Teams. 


1-  S2£ili  2-ZHamics 

The  small  size  of  these  teams  and  the  specialization 
of  function  within  them  also  helps  to  mitigate  the  negative 
impact  of  such  social  dynamics  as  the  "Commons  Dilemma" 
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[Ref.  9]  and  "social  loafing"  [Ref.  10].  These  dynamics 
suggest  that  individuals  in  a  group  may  use  more  than  their 
share  of  a  comecn  resource  or  contribute  less  than  their 
share  to  the  common  effort  if  they  feel  that  their  excesses 
or  delinquencies  will  not  be  distinguishable  from  the  common 
consumption  or  effort.  The  small  size  of  the  team  and  the 
specialized  functions  of  the  team  members  in  the  chief 
programmer  team  concept  alleviate  these  problems  by  making 
each  team  member  accountable  for  a  visible,  distinct  segment 
of  the  group  effort. 

2.  Desiqp  C cnsideratio ns 

In  order  to  reap  the  benefits  of  small  groups  such 
as  the  chief  programmer  teams  in  large,  complex  projects  it 
is  necessary  to  have  many  of  these  teams  working  concur¬ 
rently  in  coordinated  fashion.  To  minimize  the  coordination 
and  management  required,  and  thereby  enhance  the  productive¬ 
ness  of  each  team,  it  is  essential  that  the  overall  system 
be  designed  in  a  structured,  modular  manner  with  clear, 
unambiguous  specifications  and  decuman  ration.  Such  stan¬ 
dardized  design  methodologies  will  be  discussed  later  in  the 
paper.  Their  benefit  is  that  they  allow  independent, 
concurrent  production  of  modules  which  can  be  "integrated 
into  the  whole  without  further  coordination."  [Ref.  4:  p. 
10] 

D.  SOHHARY 

The  above  analysis  indicates  that,  in  a  systems  develop¬ 
ment  prelect,  the  size  of  the  work  croups  should  be 
relatively  small.  The  benefits  of  these  small  work  groups 
lie  mainly  in  the  improved  percentage  of  time  spent  produc¬ 
tively.  This  benefit  results  not  only  from  the  fewer  number 
of  communications  within  the  group;  but  also  from  the 
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ability  cf  small,  hierarchically  structured  groups  to  miti¬ 
gate  soae  of  the  non-productive  aspects  of  group  dynamics. 
Certain  managerial  and  system  design  techniques  may  be 
required  to  ensure  that  these  benefits  result.  These  tech¬ 
niques  include: 

-  Proper  scheduling  and  task  loading  based  on  an 
understanding  of  productive  time. 

-  Clear  assignment  of  task  and  product  responsibility, 
accompanied  by  measurement  and  recognition  of 
individual  performance. 

-  Modular  desian  that  supports  clear  assignment  of 
product  responsibility.  [Ref.  4:  p.  10] 
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1.  B BISOBS  FOB  STAIOABOIZ1TIOB 

Standardization  of  activities  is  a  very  important 
element  of  organizational  structure  because  it  is  the  way  in 
which  the  organization  ensures  that  its  efforts  will  produce 
predictable  results  in  the  quantity,  quality,  timeliness, 
and  cost  of  the  software  produced.  In  activity  is  standard¬ 
ized  when  the  procedure  is  mads  uniform  and  consistent. 

The  advantages  of  standardization  of  activities  have 
long  been  recognized  in  production  processes.  In  an  automo¬ 
bile  assembly  line  the  order  in  which  activities  are 
performed,  the  manner  in  which  they  are  performed,  the  qual¬ 
ifications  of  workers,  the  rate  of  production,  the  tools, 
parts,  etc.,  are  ail  highly  standardized.  This  standardiza¬ 
tion  is  one  of  the  reasons  that  this  type  of  production  is 
so  successful.  There  are,  of  course,  significant  differ¬ 
ences  between  automobile  assembly  and  software  development, 
but  the  benefits  of  standardization  of  activities  are  recog- 
nizeabl?  in  both  areas. 

The  goals  of  standardization  are  to  produce  predictable 
results  in  quantity,  quality,  timeliness,  and  cost.  The 
quantity  metric  could  be  lines  of  code,  number  of  modules, 
applications  programs  completed,  etc.,  depending  on  manage¬ 
ment's  desired  control  system.  The  quality  metric  is  a 
complex  and  multifaceted  one.  What  constitutes  good  soft¬ 
ware  is  a  question  that  continues  to  be  debated. 
Reliability,  predictability,  readability,  maintainability, 
modif iabilty,  flexibility,  robustness,  efficiency,  and 
underst ar.dabilit y  are  soma  of  the  concepts  currently  associ¬ 
ated  with  evaluating  the  quality  of  software. 
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The  timeliness  and  cost  aetrics  are  fairly  siaple 
concepts.  The  tine  it  tikes  to  complete  a  project  and  the 
cost  of  the  project  will  vary  with  the  nature  of  the 
project,  assigned  resources,  etc.;  with  the  general  goal 
being  tc  coaplete  the  project  within  the  budgeted  cost  and 
tiae  period.  The  predictability  of  the  above  aetrics  is 
Itself  a  aajor  goal  of  standardization.  Proa  a  management 
viewpoint,  the  predictability  of  the  outcome  of  the  organi¬ 
zation’s  efforts  is  absolutely  essantial  for  the  planning 
and  control  of  those  efforts. 


B.  SOFTWARE  ENGINEERING 

The  field  cf  software  engineering  has  developed  in 
response  to  the  need  to  iaprove  and  standardize  the  aethods 
and  techniques  employed  in  the  software  development  process. 
There  have  been  various  attempts  to  define  the  field  of 
software  engineering.  Wasserman  ar.i  Freeman  [Ref.  11] 
defined  it  as: 


the  attempt  to  seek  out  and  use  techniques  that  can 
assist  in  the  economical  deveiooment  of  software  which 
executes  reliably  and  efficiently  on  real  machines, 
aaking  effective  use  of  the  human  resources  available. 
Software  Engineering  tries  to  take  an  overall  systems 
viewpoint  in  which  the  optimization  of  all  resources  - 
developmental  as  well  as  operational  -  is  considered. 
[Ref.  11:  p.  256] 


B.W.  Boehm  (  Sef .  12]  shows  a  slightly  different  perspec¬ 
tive  in  his  definition  of  software  engineering  as; 


which  we  attempt  to  produce  all  of  this 
way, that  is  both  cost-ef f ective  and  reli- 
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associated  documentation  required 
and  maintain  them.  [Ref.  12:  p. 
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The  decision  of  which  techniques  and  methodologies  to 
utilize  in  the  software  development  process  is  a  choice  of 
the  technology  to  employ.  This  choice  is  of  critical  impor¬ 
tance  to  the  development  process  because  the  technology 
employed  serves  to  define  the  software  production  function. 
"The  production  function  summarizes  the  characteristics  of 
the  existing  technology  at  a  given  point  in  time;  it  shows 
the  technological  constraints  than  the  firm  must  reckon 
with."  [Eef.  5:  p.  146]  Therefore,  by  selecting  certain 
techniques  and  methodologies,  and  implementing  them  as  stan¬ 
dards  for  the  conduct  of  the  development  process,  the  choice 
of  the  technology  which  will  form  the  boundary  of  the  organ¬ 
ization's  productivity  is  made.  The  importance  of 
structured,  modular  software  design  to  the  implementation 
and  effectiveness  of  small  project  teams  was  discussed 
earlier  in  this  paper.  To  provide  continuity,  design  meth¬ 
odologies  will  be  used  as  the  example  of  how  activities  in 
the  development  process  are  being  standardized  to  contribute 
to  the  success  of  software  development  projects. 

C.  THE  DESIG1  PMSE 

The  importance  of  standardizing  the  design  phase  of  a 
software  development  project  has  grown  with  that  of  the 
design  phase  itself.  Developing  standard  design  methods  is 
one  of  the  thrusts  of  software  engineering  and  many 
approaches  have  been  championed.  The  standard  approaches 
that  have  been  most  widely  accepted  are  those  which  advocate 
a  structured  approach  to  the  design  process.  The  very  term 
"structured"  implies  that  seme  sort  of  standard  method, 
mechanism,  or  approach  is  used.  Stevens,  ayers,  and 
Constantine  [Bef.  13]  have  defined  structured  design  as  "a 
set  of  proposed  general  program  design  considerations  and 
techniques  for  making  coding,  debugging,  and  modification 


32 


easier,  faster,  and  less  axpensive  by  reducing  complexity." 
[Rmf.  13:  p.  216] 

i •  2 cfirfiasa 

Perhaps  the  best  known  structured  design  technique 
is  Top-down  design  which  results  from  a  stepwise  refineaent 
process.  Stepwise  refineaent  is  a  aethodology  which 
consists  of  the  following  steps: 

1)  Start  with  a  high-level,  overall  statement  or 
description  of  the  desired  system  function  made  up 
of:  a)  the  overall  statement  of  the  system  function; 
and  b)  comments/descr ipt ion  of  the  next  level  of 
detail. 

2)  Refine  the  above  by  replacing  the  ccmments/description 
with  a)  lower  level  functions;  and 

b)  comment  s/description  of  the  next  level. 

3)  Repeat  the  refinement  until  there  are  no  comments  left 
so  that  the  bottom  level  consists  only  of  functions 
which  can  be  implemented  on  the  ha rd war®/sof tware 
machine. 

This  Top-down  design  can  be  represented  as  a  hier¬ 
archy  of  modules  in  which  the  "uses"  relationship  exists 
between  the  higher  and  lower  level  nodules.  The  "uses" 
relationship  can  be  interpreted  as  "requires  The  presenc®  of 
a  correct  version  of."  fSaf.  1ft:  p  230] 

Brooks  tBef.  3]  termed  Top-down  design  "the  aost 
important  new  programming  formulation  of  the  (1970-1980) 
decade."  f  Hef.  3:  p.  14ft]  Among  the  benefits  that  Brooks 
attributed  to  Tcp-down  design  were  four  ways  in  which  it 
assists  the  designer  to  avoid  errors  or  bugs: 

First,  the  clarity  of  structure  and  representation  makes 
the  precise  statement  of  requirements  and  functions  of 


the  modules  easier.  Second,  the  partitioning  and 
independence  of  modules  avoids  system  bugs.  Third,  the 
suppression  of  detail  makes  flaws  in  the  structure  more 
apparent.  Fourth,  the  design  can  be  tested  at  each  of 
its  refinement  steps,  30  testing  can  start  earlier  and 
focus  on  the  proper  level  of  detail  at  each  step." 

[  Bef .  3s  p.  14  31 

The  concepts  of  modularity  and  clear  structure 
present  in  the  Top-down  design  approach  are  represented  in 
the  more  resent  design  approaches  although  the  manner  and 
criteria  of  the  decomposition  have  varied  in  some  cases. 

2  .  f  or  Change 

Parnas  t  Bef •  “15]  has  proposed  a  design  methodology 
which  focuses  on  designing  software  that  can  be  easily 
changed.  His  approach  uses  a  modular  decomposition  based 
upon  information -hiding  modules  within  a  hierarchical  struc¬ 
ture.  Parnas  tlef.  151  proposes  a  design  procedure  which 
would  include: 

1)  Identifying  all  difficult  design  decisions  and  these 
design  decisions  which  are  likely  to  chance. 

2)  Isolating  the  changeable  design  decisions  into 
information-hiding  modules  with  clearly  defined 
interfaces  which  will  be  unaffected  by  potential 
changes. 

3)  Establish  the  "uses”  relationship  between  the  modules. 

4)  set  up  the  "uses”  hierarchy  by:  a)  listing  the  modules 
at  level  0  (i.e.  those  modules  which  use  no  other 
module)  ;  and  t)  working  up  the  hierarchy  to  the  top 
level  (i.e.  that  module  which  is  used  by  no  other 
module) . 


Parnas'  approach  to  system  design  has  been  of 
significant  interest  to  those  in  the  software  engineering 
field  because  his  sethods: 

1)  Bring  software  design  closer  to  being  a  science. 

2)  Result  in  prograss  which  are  easier  to  fix  and  modify. 

3)  Result  in  progress  which  are  easily  subsettable  and 
extendable. 

4)  Allow  modules  z o  be  progressed  and  rested 
independently  (Hef.  15]. 

Note  that  the  ability  to  independently  program  and 
test  aodules  which  is  cited  here  and  in  susequent  design 
techniques  is  what  was  shown  to  be  naccessary  for  the  effec¬ 
tive  utilization  of  small  project  teams  wirhir.  a  large, 
cos  pi  ex  project. 

3,  £s§igil  Z.Q-L  SiiEli  Connect  ions  and  Functional  Binding 

Stevens,  Myers,  and  Constantine  [Bef.  13]  have 
proposed  structured  design  techniques  based  on  principles 
similar  to  those  of  Parnas.  These  techniques  emphasize  a 
structure  of  simply  connected,  functionally  bound  modules. 
Thay  emphasize  the  use  of  structure  charts  rather  than  flow¬ 
charts  in  the  design  phase.  Reference  13  provides  the 
somewhat  lengthy  step-by-step  procedure  for  developing  the 
input-process-output  general  structure  that  Stevens,  Myers, 
and  Constantine  advocate. 

The  benefits  of  this  design  technique  include: 

1)  Its  compatability  with  the  HIPO  hierarchy  charting 

format  (Ref.  16]. 

2)  Better  maintainability  of  resultant  programs. 

3)  Results  in  independently  programmable  and  testable 
modules. 
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4)  Ability  to  identify  and  optimize  critical  nodules. 

5)  Ability  to  develop  reuseable  nodules. 

4.  Eaaiaaias  Si§tg»s  is  &4sU 

Jackson  [lef.  17]  has  proposed  a  different  approach 
to  software  design.  He  argues  that  there  are  soae  serious 
disadvantages  to  the  functional  approach  to  systems  design. 
Among  the  disadvantages  ha  cites  are: 

1)  The  difficulty  of  applying  functional  design  tc  complex 
problems. 

2)  The  frequent  requests  for  changes  in  system  function. 

3)  The  lack  of  a  clear  distictior.  between  functions  to  be 
performed  by  software  and  those  to  be  performed  by 
hardware. 

Jackson' s  approach  is  to  design  the  system  primarily 
as  a  model  of  the  reality  which  it  is  representing  and 
subsequently  superimpose  the  desired  functions  on  the  model. 
The  steps  in  the  process  are: 

1)  Represent  each  active  entity  in  the  real  world  system  to 
be  modeled  as  a  process  acting  on  a  dedicated  processor. 

2)  Represent  the  communication  between  the  processes 
themselves,  and  between  the  processes  and  the  outside 
world  as  a  data  stream. 


3)  Superimpose  desired  functions  on  the  model. 


Menard  [  Bef  .  18]  of  the  Communications  and  Computer 
Science  Department  of  Ezxon  corporation  has  ased  Jackson’s 
design  method  in  c cabinet! on  with  top-down  implementation 
and  structured  walkthroughs.  This  combination  was  called 
the  Program  Structure  Technology  (PSP) .  Menard  found  that 

the  benefits  derived  from  the  use  of  PST,  measured 
statistically  for  several  applications,  include 
increased  programmer  productivity  and  reduced  mainte¬ 
nance  costs.  With  PST  as  a  design  method,  the 
programmer  can  produce  double  the  industry  standard 
number  of  lines  of  code  per  year.  The  reduced  mainte¬ 
nance  costs  result  from  encountering  fewer  buns  in  the 
program  code  and  from  having  the  simpler,  structured 
code  which  is  easier  to  modify."  [Bef.  18:  p.  89] 

Menard  [  Bef .  18]  found  that,  whereas  the  PST  method 
required  them  to  spend  more  time  on  the  design  phase  of  a 
project,  this  time  was  more  than  made  up  in  the  implementa¬ 
tion  phase  of  the  project. 

D.  SU1HAHY 

The  design  aethodclogie  s  discussssd  above  are  important 
fcr  providing  conceptually  sound  frameworks  for  the  design 
of  "good"  software;  but,  in  order  to  realize  the  maximum 
benefit,  the  chosen  methodology  must  be  standardized 
throughout  the  development  project.  It  is  the  standardiza¬ 
tion  of  the  process  which  provides  the  organization  with  the 
benefits  by  reducing  the  necessity  for  communication  and 
coordination  while  maintaining  design  integrity  and  facili¬ 
tating  successful  integration. 

The  standards  themselves  fora  the  basis  of  the  organiza¬ 
tion's  planning,  control,  and  evaluation  processes.  Biggs, 
Birks,  and  Atkins  [Bef.  19]  summarized  the  importance  of 
standardization  as  fellows: 

The  standard  approach  to  phases,  steps,  activities,  and 
tasks  makes  it  possible  to  plan,  control,  and  evaluate 
progress  during  the  systems  development  process  without 
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inhibiting  the  necessary  analytical  and  creative  work 
required  to  produce  successful  new  systems.  The  struc¬ 
ture  allows  management  tp  Bake  and  monitor  incremental 
commitments  and  the  ability  tc  impact  interim  results. 
It  is  an  important  key  to  an  organization's  effective 
management  of  the  systems  development  process. 
[Bef?  19:  p.  4  7}  1 


The  importance  of  standardizing  the  activities  in  the 
software  development  process  continues  to  receive  management 
attention.  The  emphasis  on  developing  standard  methods  and 
approaches  to  reauireaents  analysis,  specifications,  docu¬ 
mentation,  integration,  and  testing  manifests  the  vital 
importance  of  activity  standardization  ir.  the  software 
development  process. 
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SUMMARY  AND  CONCLUSIONS 


Organizational  structure  has  long  been  recognized  as 
having  an  important  impact  on  an  organization’s  ability  to 
accomplish  its  objectives.  Managers,  therefore,  need  tc  be 
aware  of  how  organizational  structure  affects  performance. 
This  paper  has  provided  the  managers  of  software  development 
projects  with  an  analysis  of  one  importance  of  several 
elements  of  organizational  structure,  and  cf  how  they  can 
use  this  knowledge  to  make  decisions  about  organizational 
structure  which  will  hava  a  positive  impact  on  the  success 
of  their  projects. 

The  first  structural  element  analyzed  was  the  speciali¬ 
zation  of  activities.  It  was  found  that  the  manager  ccul? 
proceed  with  specific  or  general  knowledge  of  the  software 
production  function  as  provided  by  3rooks  [Ref.  3],  ?ri  =  i 
[Ref.  4],  Weinberg  [Ref.  7],  and  "in- Dor  and  Jones  [Bef.  6], 
tc  develop  conceptual  frameworks  to  assist  in  making  deci¬ 
sions  for  optimizing  the  utilization  of  the  SDecialized 
inputs  into  the  software  development  process.  Two  cf  the 
most  important  decisions  are  the  determination  of  the 
optimal  mix  of  these  inputs,  and  the  determination  of  the 
optimal  guantity  of  a  particular  input  to  aquire. 

The  optimal  mix  cf  the  various  inputs  was  shown  to  exist 
at  that  point  where  the  marginal  productivity  of  a  dollar's 
worth  of  any  input  in  the  production  of  the  software  cutpur 
is  equal  to  the  marginal  productivity  of  a  dollar's  worth  of 
any  other  input. 

The  optimal  quantity  of  an  input  to  employ,  other 
factors  remaining  constant,  is  that  quantity  at  which  the 
present  value  of  the  marginal  revenue  received  due  tc  a 
marginal  increment  of  the  input  is  equal  to  the  present 


value  of  the  marginal  cost  incurred  do  to  that  marginal 
increment. 

This  type  of  conceptual  framework  provides  the  addi¬ 
tional  benefit  of  being  compatible  with  technical  analysis 
and  linear  programming  as  shown  by  Ein-Dor  and  Jones 

[Bef.  6]. 

One  element  of  organizational  structure  that  affects 
labor  productivity  and  thus  the  production  function  is  the 
size  of  the  work  group.  Brooks  [Bef.  3]  found  that,  after  a 
point,  increases  ir.  programmer  labor  contributed  less  ir.d 
less  to  software  production  ar.d  that,  ultimately,  increases 
in  programmer  labor  would  have  a  negative  impact  on  produc¬ 
tion.  Fried  [ Bef.  4]  experienced  similar  results  as  did 
Weinberg  [Ref.  7].  Fried  [Ref.  4]  and  Brooks  [Ref.  3]  found 
that  communications  requirements  were  the  major  factor  in 
reduced  productivity  as  group  size  increased.  Fried 
[Ref.  4]  has  developed  a  formula  from  case  studies  and  prac¬ 
tical  experience  which  can  be  used  t  o  calculate  the  amount 
of  time  spent  stent  productively  by  a  group  based  upon  the 
size  of  *he  group.  This  formula  and  Weinberg's  [Ref.  7] 
findings  suagest  that  groups  with  more  than  3D  people  will 
spend  less  than  50  percent  of  their  time  doing  productive 
work. 

Cass  and  Edney  [Ref.  9]  and  Latane,  williams,  and 
Harkins  [Ref.  10]  discovered  aspects  of  social  dynamics 
which  also  contribute  to  reduced  individual  productivity  in 
large  groups.  These  findings  indicate  that  individuals  tend 
to  use  more  resources  and  contribute  less  effort  if  their 
consumption  and  performance  are  felt  to  be  ir.dist inqishable 
from  that  of  the  group. 

&  possible  solution  to  the  team  size  problem  in  view  of 
these  findings  is  the  chief  programmer  team  concept.  This 
hierarchically  structured,  10  person  team  is  organized  in  a 
manner  which  provides  for  design  integrity,  quality  output. 
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simple  communication  patterns,  visible  job  performance,  and 
high  productivity.  Successful  implementation  of  this  saall 
teaa  concept  in  coaplex  projects  requires  a  aodular  project 
design  as  well  as  managerial  emphasis  on  planning,  control, 
and  evaluation. 

The  achieves  at  of  good  planning,  control,  and  evalua¬ 
tion  requires  the  standardization  of  software  development 
activities  including:  requirements  analysis,  specifica¬ 
tions,  design,  dccuaentation,  integration,  and  testing.  The 
selection  and  implementation  of  standard  techniques  and 
methodologies  represents  the  choice  of  technology  for  the 
project.  This  technological  choice,  in  turn,  serves  to 
define  the  production  function  for  the  project. 

Stevens,  Myers,  and  Constantine  [Ref.  13],  Parnas 
[Ref.  15],  and  Jackson  [Raf.  17],  among  others  have  proposed 
software  design  methodologies  which  have  been  used  with 
success  as  the  standard  for  software  projects.  The  modular 
structure  and  clearly  defined  interfaces  resulting  from  the 
structured  design  methodologies  allow  for  the  successful 
division  of  work  among  small,  efficient  programming  teams. 

Biggs,  Birks  and  Atkins  [Ref.  19]  emphasize  the  impor¬ 
tance  cf  activity  standardization  in  all  phases  of  the 
development  process  as  a  key  element  of  organizational 
structure.  Its  importance  is  recognized  not  only  because  it 
makes  effective  planning,  control,  and  evaluation  possible; 
but  also  for  the  reduction  in  communication  and  coordination 
it  allows. 

The  field  of  organizational  structure  and  its  impact  on 
organizations'  success  is  vast,  with  myriad  subtle  interre¬ 
lationship^.  It  is  an  interdisciplinary  field  with 
applications  from  economics,  operations  research, 
psychology,  sociology,  and  various  technologies.  This  paper 
has  delved  into  several  of  the  relationships  between 
elements  of  organizational  structure  and  the  software 
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development  process.  A  common  thread  that  has  appeared  in 
each  element  is  the  software  development  production  func¬ 
tion.  As  the  database  of  development  projects  improves,  so 
too  will  our  ability  to  analyze  and  improve  the  software 
development  process. 
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